Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add online, weak merit based sortition without new scores yet #568

Merged
merged 29 commits into from
Sep 3, 2024

Conversation

kpeluso
Copy link
Collaborator

@kpeluso kpeluso commented Aug 31, 2024

Purpose of Changes and their Description

Why "Weak"?

@jmdkastro formulated a well-defined theory of merit-based sortition plus simulation. This rhymes with that, but is not exactly that.

A consequence of #567 will be way greater stagnation in the active set, as those with scores have an actual opportunity to make it into their topic's epochs. Hence, there is a need to quickly add a non-corrosive form of permeability to the network. This route maximizes our ability to serve large cohorts of workers while enabling for more sophisticated methods later, potentially as fast-follows.

How it Works

Definition

  • Active set = Your inference/forecast/reputer loss payload is considered as part of rewards/inference synthesis calculations
  • Passive set = Your inference/forecast/reputer loss payload is not considered as part of rewards/inference synthesis calculations

We differentiate between these 2 sets because calculations for the active set are expensive => this must be bounded. However, we must cycle through participants, so we now need a name for those "passively considered" actors.

When scores are calculated in rewards

  • An EMA score is updated for each actor of each type
  • A topic-defined quantile of the active set is taken for each actor type (inferer, forecaster, reputer)
    • This will be used in the next epoch
    • For example if EMA score among active set is [10,20,30] then topic quantile might be 12 (linear interpolation)

In the next epoch

  • We skim the top in an online fashion i.e.
    • If we have not yet met our limit per actor type per epoch, then we add the actor payload to the active set
    • If we have met our limit per actor, then we ask if the EMA score of the new actor is better than the lowest in the current active set.
      • If yes, then we pop the lowest scorer by EMA score out of the active set and update their EMA using the topic quantile of the previous epoch
      • If no, then we update the EMA score of the rejected actor using the topic quantile of the previous epoch

In summary, if you're in the active set, your EMA score gets updated based on your performance in this round, and if you're int he passive set, your EMA score gets updated based on the performance of the previous epoch's active set. In either case, we do calculations in an online fashion => the true limit of actors for which we can do calculations is the cumulative blockspace within a worker submission window.

Link(s) to Ticket(s) or Issue(s) resolved by this PR

Are these changes tested and documented?

  • If tested, please describe how. If not, why tests are not needed.
  • If documented, please describe where. If not, describe why docs are not needed.
  • Added to Unreleased section of CHANGELOG.md?

Still Left Todo

  • Fix tests
  • Add more coverage

Copy link

github-actions bot commented Sep 2, 2024

The latest Buf updates on your PR. Results from workflow Buf Linter / buf (pull_request).

BuildFormatLintBreakingUpdated (UTC)
✅ passed✅ passed✅ passed⏩ skippedSep 3, 2024, 5:58 PM

x/emissions/keeper/actor_utils/quantile.go Outdated Show resolved Hide resolved
x/emissions/keeper/actor_utils/quantile_test.go Outdated Show resolved Hide resolved
x/emissions/keeper/keeper.go Outdated Show resolved Hide resolved
@relyt29
Copy link
Contributor

relyt29 commented Sep 2, 2024

so this architecture design, the only way for a new participant to break in is to be first / early?

if they don't have a good score and they try to upload an inference, their TX is rejected/fails and nothing happens

But if they're early at least they land into the active set and then are later booted out of it and given a quantile

when we spoke on thursday I had pitched an idea of allowing passive actors to upload and get their score set to the quantile even if they're not getting picked in the active set, but the issue was the abuse of the quantile multiple times, so you only allow someone to do that once per epoch

@kpeluso
Copy link
Collaborator Author

kpeluso commented Sep 2, 2024

@relyt29 this implements the online, unbounded approach where we check if they submitted already in this epoch before including them again. We use the quantile from the previous epoch's active set to update everyone in the passive set. This does not favor those who came first -- anyone below the topic quantile by EMA score is liable to be sub'd out for someone with better EMA score if they present themselves. Their score will be updated using previous epoch's topic quantile, which is by definition better than an earlier active participant who scored below that quantile.

@relyt29
Copy link
Contributor

relyt29 commented Sep 2, 2024

To be clear, this is the attack i am concerned about (we should write a unit test and confirm we prevent this case):

it is now epoch 5. The quantile score from epoch 4 is 75.

Alice has a current score of 50. TopN has been filled at this point in the epoch, and the cutoff score is say, 67.

Alice submits an inference. Her score is lower than 67, so she's not allowed into the active set. The chain takes her score 50, and computes an EMA with 75 the quantile from last epoch. 75*0.9 + 0.1*50 = 72.5 which is now stored in the chain as alice's score

Alice, in the same epoch, submits her inference again. Her score is now above 67 so she's let into the active set.

OR, depending on the numbers maybe she can't make it into the active set, but she can force the algorithm to recalculate her EMA again with 75. She can do this as many times as she wants until her score is infinitesimally close to 75.

To be clear I am not alleging that we are susceptible to this attack, just that we need to adequately test for it. I do see we check if the inference is already accepted, but I don't see that the negative case-where Alice is not in the active set, updates that data structure so at this point i'm not convinced the attack is thwarted.

@kpeluso
Copy link
Collaborator Author

kpeluso commented Sep 3, 2024

@relyt29 Good call on the attack and thank you for explanation. I tested this as part of TestAppendInference unit test. Please review.

@kpeluso kpeluso marked this pull request as ready for review September 3, 2024 05:58
Copy link
Contributor

@relyt29 relyt29 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR builds off quite a bit of work from #548, which I wrote so I am familiar with it.

The rest looks good based on my (twice now) reviews. I think the attack I described earlier is covered as well, though I will be looking to add unit test coverage now

relyt29 and others added 10 commits September 3, 2024 10:12
## Purpose of Changes and their Description

This adds a query function that lets inferers, forecasters, and reputers
to check what the cutoff boundary is for making it into the active set,
before sending a transaction on chain

## Are these changes tested and documented?

Adds `TestGetCurrentLowestXScore` functions in
`x/emissions/keeper/queryserver/query_server_score_test.go`
…etwork/allora-chain into feat/weak-merit-based-sortition
…etwork/allora-chain into feat/weak-merit-based-sortition
@kpeluso kpeluso merged commit ab4b3ab into release-v0.4.0 Sep 3, 2024
7 checks passed
@kpeluso kpeluso deleted the feat/weak-merit-based-sortition branch September 3, 2024 18:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants